There are many circumstances in which online resources should only be accessible to authorized people. For example, a company's employee directory may a resource that only authorized people should be able to see. Accordingly, many systems have been developed to determine whether a person seeking to access a resource is authorized to access the resource.
The Organization for the Advancement of Structured Information Standards (OASIS) has advanced a set of related standards for determining whether users are authorized to access web services. These standards include WS-MetadataExchange, WS-Security, WS-Trust, WS-Federation, and others. Typically, a web service is an application programming interface (API) that is accessed via Hypertext Transfer Protocol (HTTP) and executed on a remote system that hosts the requested service. For example, a web service can be a web API that provides access to a company's employee directory. A web API is an API that is accessed via HTTP and executed on a remote system that hosts the requested service.
The standards advanced by OASIS rely at least to some degree on the exchange of security tokens. A security token is a data structure representing a collection of claims. A claim is a declaration by an entity. A web service can require users to present security tokens issued by a Security Token Service trusted by the web service in order for the web service to allow the users to access the web service. Moreover, the security tokens must include certain claims. For example, a web service can require security tokens to include claims declaring that the users are in the accounting department of a company.
The WS-Federation standard provides for at least two ways for a client to obtain a security token from a Security Token Service and to use the security token to access a web service. These ways include the WS-Federation Passive Requestor Profile and the WS-Federation Active Requestor Profile. Clients that do not utilize the SOAP protocol typically use the WS-Federation Passive Requestor Profile. For instance, web browser applications typically use the WS-Federation Passive Requestor Profile to obtain and use security tokens. Clients that utilize the SOAP protocol can use the WS-Federation Active Requestor Profile. Thick-client applications, such as workplace productivity applications, typically use the WS-Federation Active Requestor Profile to obtain and use security tokens. In some instances, clients using the WS-Federation Active Requestor Profile can obtain and use security tokens more efficiently than clients using the WS-Federation Passive Requestor Profile because fewer messages may need to be sent across a network when using the WS-Federation Active Requestor Profile.
In some instances, a client may use both the WS-Federation Passive Requestor Profile and the WS-Federation Active Requestor Profile. For example, a complex thick-client application can include several components developed at different times. In this example, an earlier-developed component in the client application can be programmed to use the WS-Federation Passive Requestor Profile to access a web service while a later-developed component in the same client application can be programmed to use the WS-Federation Active Requestor Profile to access the same web service. In this example, a client application can include components that use the WS-Federation Passive Requestor Profile and components that use the WS-Federation Active Requestor Profile because it may be too costly to reprogram the components to use the WS-Federation Passive Requestor Profile.
In instances where components of a client application use both the WS-Federation Passive Requestor Profile and the WS-Federation Active Requestor Profile, a user may need to provide a credential when one component of the client application uses the WS-Federation Passive Requestor Profile to obtain a security token to access a web service. For instance, a user may need to provide a username and password when one of the components uses the WS-Federation Passive Requestor Profile to obtain a security token to access a web service. Subsequently, the user may need to provide the same credential again when another component of the client application uses the WS-Federation Active Requestor Profile to obtain a security token to access the same web service. The user may find it annoying to provide the same credential twice to access the same web service.